1. Field of the Invention
This invention relates to routing data across computer networks. More specifically, this invention relates to data routing among distributed networks over the Internet. Still more particularly, this invention relates to distributed, fault-tolerant, load-balanced, managed application data routing among distributed application end points hosted within peer nodes of a service oriented architecture (SOA).
2. Background of the Related Art
With the advent of web services and the Web Services Interoperability (WS-I) family of specifications, mechanisms are evolving that support loosely coupled communication among families of disparate applications across a ubiquitous network.
Service oriented architectures have existed before in forms, such as Common Object Request Broker Architecture (CORBA) and Distributed Computing Environment (DCE), but they were limited by the necessity of tightly coupled interfaces and limited network reach. The service oriented architectures evolving from the WS-I specifications have the potential to have a much larger impact, because of their trans-enterprise scope, support for large-grain loosely coupled connections, and the ability to connect services exposed by loosely affiliated enterprises and organizations.
Most web services being deployed today are being implemented in a service oriented architecture defined by the specification trinity of Simple Object Access Protocol (SOAP), Web Services Definition Language (WSDL), and Universal Description, Discovery, and Integration (UDDI), with the Hypertext Transport Protocol (HTTP) as the primary transport mechanism. Unfortunately, this form of SOA is severely limited, owing to a combination of brokering and transport limitations. The basic SOA approach is described with reference to FIG. 1.
Referring to FIG. 1, UDDI 100 is a database of Service Providers. A Service Requestor 110 queries a UDDI repository to discover services of a particular type. However, after the consumer has discovered a service it must query the Service Provider 120 directly to discover the detailed requirements for communication with the service. Additionally, UDDI 100 is a store of persistent service registrations and has no knowledge of the current status of a Service Provider 120.
Services are registered in UDDI when they are deployed; there is no mechanism for updating those persistent registrations with transient status information. The consumer must take its chances that the service will be available when a request is made and will only discover that the service is unavailable when a fault occurs. The Web Services Distributed Management (WSDM) specification adds some support for historical statistics of a service's availability, but does not satisfy the core requirement to know the status right now, to support dynamic routing of requests to available service instances. There is no provision either in the UDDI specification or with the HTTP protocol discussed below for heartbeat or other availability monitoring, to obtain and disseminate up-to-date service status information.
SOAs based on UDDI also require that the Service Consumer communicate directly with the Service Provider. There is neither location nor instance opacity. The requesting application is directly bound to the Service Provider and must itself manage issues such as load distribution among multiple services of a particular type, fault tolerance, and intermittent availability.
Because the connections described above are inherently point-to-point with persistent bindings, it is not possible adequately to manage fault tolerance, request prioritization, service level agreements, and load distribution among multiple services of a given type because there is no central routing mechanism at the application layer. In practice, bindings are established at the time of design or implementation, and there is no effective mechanism to coordinate the efforts of multiple services of an equivalent type and context. All requests from a particular consumer go to the same provider even if that provider is overloaded or even if another instance of the provider is available elsewhere with low load. With this form of SOA every consumer would have to implement its own load balancing approach to partially resolve this problem.
To contend with the lack of dynamic routing and binding within the UDDI-based SOA model, services must be implemented as heavily managed horizontally scaled services “hidden” behind a single Uniform Resource Identifier (URI)/Uniform Resource Locator (URL) Proxy service. Behind that address, multiple instances of a single type may be deployed with load balancing, fault tolerance, and other management functions provided at the network layer. If in fact these services' instances are not owned or managed by the same organization and therefore cannot be organized behind a single URL or domain, this method will not work and routing at the application layer becomes necessary.
Perhaps an even larger limitation of SOAs of this form is imposed by the underlying transport mechanism, HTTP. HTTP is a synchronous request and response (client/server) protocol. It is rapidly becoming the de facto standard for the transport of application data associated with web services. Unfortunately, HTTP does not provide capabilities to support routing, registration, subscriptions, or events. While services can be deployed via this protocol, they will lack many benefits that could be provided by a protocol that offered those other capabilities.
Service implementations tend to conform to two models: Request/Response and Publish/Subscribe.
Request/Response services invoked via a message delivered by HTTP will have the disadvantage of requiring the consumer to synchronously wait for the response. This is a tremendous disadvantage, especially in cases where the service response takes more than a trivial amount of time to construct.
HTTP's synchronous nature and lack of timeout and retry mechanisms makes it less than ideal for Request/Response service interaction. However, its limitations are even greater for Publish/Subscribe or other event-driven service interactions. Because HTTP doesn't natively support NOTIFY, SUBSCRIBE, or INVITE interaction types, these methods must be built in an ad hoc manner on the synchronous HTTP POST interaction. In turn, this requires all Service Consumers who desire to participate in these interaction model types to run an HTTP server to receive those synchronous posts.
In summary, the shortcomings of a UDDI/HTTP based SOA include the following:                a) Service Provider Registrations are persistent and do not reflect the current availability or status of a particular instance.        b) A Service Consumer that discovers multiple Service Providers via this mechanism will have to choose one instance of a particular type with which it should transact and will have no means to accomplish effect fault tolerance, load balancing, or service level agreement (SLA) management.        c) Once a Service Consumer and Service Provider have forged such a “relationship,” their interaction will continue even if another Service Provider instance is better able to satisfy the requests, unless the Service Consumer is programmed or otherwise equipped to carry out the complex task of identifying other Service Provider instances.        d) With no way to centralize knowledge about the instances of a Service Provider type, there is no way intelligently to manage load balancing and SLA management.        e) Load balancing must be accomplished at the Network Layer which assumes that all instances of a Service Provider can be located at a single virtual network address.        f) HTTP is a synchronous protocol and forces Service Consumers to block while awaiting a response.        g) HTTP does not automatically support Notifications, Subscriptions, Invitations, and other interaction types useful in a distributed application data routing environment, especially where support of Publish and Subscribe mechanisms is required.        
The Session Initiation Protocol (SIP) is a telecommunications signaling protocol used to deliver services such as Voice over Internet Protocol (VoIP), and, when extended to be the SIP Instant Messaging and Presence Leveraging Extension (SIMPLE), instant messaging. SIP is used primarily in telecommunications and collaboration but offers many features that may be useful in the implementation of a Peer-to-Peer Application Data Routing Fabric.
SIP provides the following functions or message types:                REGISTER        INVITE        BYE        ACK        CANCEL        
These message types are used as signaling to establish asynchronous peer-to-peer sessions between mobile entities (e.g., a person whose VoIP presence may move from device to device as that person logs in to different computers), frequently to establish a phone call between two end points.
The SIP protocol also establishes specifications for the Registrar and Proxy devices that handle the actual routing of messages. Messages are addressed in the form “SlP:jim@camden.com” where “jim” is the entity name and “camden.com” is the entity's home domain (and location of the controlling SIP Proxy).
SIMPLE adds the following functions and message types:                SUBSCRIBE        NOTIFY        MESSAGE        
SIP also adds the specification for a Presence server that manages subscriptions and distributes notifications in response to subscriptions.
A SOA that leveraged the SIP and SIMPLE standards and associated protocols would offer a number of advantages over one based solely on UDDI and HTTP. The combination of transient status management, additional interaction types, and the asynchronous transport supported by these protocols may satisfy a number of the issues raised above. However, SIP and SIMPLE in their current forms still have the following shortcomings:                a) SIP doesn't support the idea of “equivalent” entities or end points. SIP is instead oriented around collaboration facilitation where the end points are usually humans who are not interchangeable the way multiple instances of an application may be.        b) SIP doesn't natively support efficient application data routing by service type. SIP addresses always include the domain and, by implication, an entity instance.        c) SIP does support forking of messages to one or more instances of an entity (usually to ensure that a user logged into multiple devices will receive a message), but doesn't natively apply rules (e.g., load balancing or fault tolerance) to dynamically route to a single instance of the invoked entity.        d) SIMPLE provides a MESSAGE interaction, but that interaction does not natively support remote service invocation by implementing protocols in the message payload, such as SOAP.        e) SIP provides support for routing to an entity known by its primary domain, even if that entity is currently residing on a device in a remote domain. However, SIP does not have a native capability to discover dynamically an entity whose home domain is remote, unless that domain name is included in the invocation address.        f) The SIP heartbeat provides a mechanism to notify the SIP Registrar, Proxy, and Presence servers that an entity is no longer available; however, it does not natively carry as a payload additional end point status information that would be critical to the support of SLA, quality of service (QoS), and load balancing management.        g) SIP messages support “end point priority” content but that content is insufficient to support SLA, QoS, and load balancing Management.        h) The preponderance of services and Service Consumers deployed today are not SIP end points but must be participants in an effective SOA. SIP does not natively enable invocation of SIP-based end points via protocols other than SIP.        i) The SIP protocol assumes that an “inviting” end point knows the address of the “invited” end point, and so does not make provisions for dynamic discovery of end points by type or other attribute. SIP makes no provision for the utilization of UDDI to support discovery.        